Note: this post is a work in progress.
Last night at RUM there was a presentation (by unknown) which addressed the issue of “telecomputing” (trendy word for telecommuting), using Rails + Trac + Campfire on a project with a global development effort as a model. There were a few major points to his project's successful approach:
Use Conventions From Rails Manual
”Convention over configuration” is the motto Rails was developed by. The presenter addressed an all-too-familiar sentiment of seeing Ruby degenerate into something resembling PHP, as soon as the code deviates from the standard conventions too much. To nip this issue in the bud, his team adopted a strictly convention-centric approach--if it's not in the manual, don't do it. (note: I don’t actually know what book he’s referring to, please enlighten me if you know)
Use a "Torch Passing" Technique for Global Development Teams
This was the first time I had heard the term "torch passing" in this context, but I think it is a perfect analogy for its purpose. Torch passing is what it sounds like: having people in one location brief the next team in chronological order about the day's work, and hand leadership to the new them. In this way, with no central team leadership, a global development effort is not working headless for 24-48 hours at a time.
One member of the audience shared his belief that communication will never be as good as when a person is working next to you, which I think can be true depending on the task at hand. His specific example was when a designer made incorrect attempts to fix defects in a GUI; that had 48 hours wasted between each iteration. Perhaps if leadership were passed around the globe throughout the day, rather than remaining static, this issue would disappear.
Use Skype for conference calls
Skype is cheaper than phone service (free, in fact), and multi-platform. And Dan Grigsby made an interesting contribution to the subject: a study found that effectiveness of communication increases with fidelity (citation?), and Skype has about twice the fidelity of a standard phone line.
Campire
This where the meat of my interest lay. Campfire is a 37signals application that is very much like an IRC client. It is more like a Jabber MUC, however, in that conversations remain static and history is sent to new clients that enter a chat room (the past X lines, minutes, etc). After briefly looking at the video tour available on 37signals' website it seems like there are some interesting nuggets that can be added to Soashable. Namely file uploading that displays rich media directly in the chat window intelligently, presumably by mime type. Indeed, most of the product could be implemented using existing XEP-defined functionality.
I think there is lots of potential here to build a clone on the same messaging/presence platform as Soashable using existing Jabber extensions which, as I love, means minimal work on my part . As far as business goes, I have some resevations about an organization like DHS and some of the employees' (business analysts, management, etc), willingness to adopt something remotely similar to Campfire (I could be wrong). But for a smaller team in a more cutting edge environment, I think it would be great and very welcome. I can't count the number of walks across the office it would have saved me at my former employer. Maybe if there was an ugly, unintuitive interface, like Oracle products, a place like DHS would like it more ;)
I think the core advantages of using Jabber over a custom Java/Rails backend is scalability, mitigation of labor and loose coupling. By using an existing, standardized, specified platform you don't have to do a lot of things yourself. And if you do, you already have templates to explain your custom functionality.
Using Meebo as an example: they have a team of C++ developers maintaing a custom version of GAIM on their servers, and a nasty (to maintain) looking Ajax/JSON protocol. Okay, but they need scalability. With Jabber, smarter people already have that taken care of. What about the mobile interface they promised forever and a day ago? Part of me thinks that they coupled their protocol too tightly with their GUI. I was able to set up a working, web-based AIM client over the course of a weekend with little prior knowledge of Jabber. I was then able to unit test it and completely rebuild the GUI without changing a line of tested code.
You'd tell me if I were stuck in a box where all I could see is Jabber, right?